The Original Shareware 1.1

home *** CD-ROM | disk | FTP | other *** search

/ The Original Shareware 1.1 / The Original Shareware (WeMake CDs)(Volume 1.1)(CDs, Inc)(1993).iso / 30 / tbscnx29.zip / NOTES.TXT next >

Wrap

Text File | 1991-06-16 | 13KB | 245 lines

General notes for TbScan and TbScanX ------------------------------------ TbScan(X) does not mean TurBo-SCAN as some users assume, but stands for Thunderbyte Scan. TbScan and TbScanX are supplied on the Thunderbyte disk which makes part of the Thunderbyte hardware PC Immunizer package. If you loaded TbScanX in video-memory it is possible that TbScan detects signatures in upper memory. TbScanX does not always scramble the signatures to gain some speed when it is using (slow) video-memory or expanded memory. Due to safety routines in the TbScan(X) programs, it can not be compressed with programs like PkLite, LzExe, or Diet. This is not very painfull after all because the files aren't that big! TbScan and TbScanX both need a signature file TBSCAN.DAT or VIRUSSIG.DAT. Because these files are updated a lot, they are not supplied with this package. Both of these files are available at Thunderbyte support BBS +31-85-212395 (2:280/200@fidonet) or at many other BBSs. Notes concerning TbScan ----------------------- Some users think that scanning for all viruses in all files is the best scanning method (by using "TBSCAN *.* -a +n"). This is not true: It only increases the possibility of false alarms. It is not usefull to scan for bootsector viruses in .COM files or to scan for COM viruses in .EXE files. Use this option only when you already encountered a virus and want to make sure that you really destroyed all infected files. If you use the -analyze option, TbScan will issue less warnings. This is due to the fact that the -analyze option disables the code interpreter of TbScan. And the code interpreter is the routine that is able to detect suspicious code. The -analyze option converts the scanner to a normal, conventional (but also very fast) scanner. If you run TbScan AFTER you executed another scanner, it is possible that TbScan finds signatures of viruses in memory. This does not mean that you have a virus, but is caused by the fact that TbScan detects the search-signatures left in memory by the other virusscanner. If you have a disk caching system it is recommended to disable the cacher, because TbScan will be faster in that case. While TbScan is scanning, the cacher keeps trying to determine what is going on, storing megabytes of data in its buffers, but TbScan will read every byte only once, and all clock cycles spend by the cacher to maintain the data are completely lost! So, switch that cacher temporary off, it can speed up the operation of TbScan with up to 20 percent! Thunderbyte users who have a language file installed should download the most recent language file, because only the most recent language file contains the new texts of TbScan. Notes concerning TbScanX ------------------------ TbScanX is Windows 3.0 aware. It is recommended to load TbScanX BEFORE starting Windows (even in 386-enhanced-mode). TbScanX will not interfere with copies of it running in other DOS windows. It is even possible to disable TbScanX in one window while it is still enabled in another window. With other words, TbScanX maintains a separate data area for every DOS-window. If you use a local area network you should invoke TbScanX AFTER the network software. Otherwise, TbScanX will not be able to detect if a remote file is being created/opened. In that case TbScanX will only be functional for the local drives. Although TbScanX is very reliable, you should regulary use a normal transient scanner like TbScan, especially after an alarm of TbScanX. Some people think that we went mad to implement an option to switch TbScanX off, because viruses can switch off TbScanX too! But, it is not dangerous at all. TbScanX detects a virus as soon as it is copied to your system, or before it is being executed. At that time the virus did not have the opportunity to switch TbScanX off at all! Of course, after the virus becomes active (and you ignored the first TbScanX warning), the virus could switch off TbScanX or completely remove it from memory. This applies to all resident anti-virus software. If you want a real weapon against viruses that always survives a viral attack we recommend Thunderbyte... Notes concerning the format of the signature file ------------------------------------------------- The format of the signature file (also called data file) is covered completely in the manual on disk. However, there are more scanners using the same signature file (virscan.dat) as compiled by Jan Terpstra. Unfortunately, not all scanners use the same format. There is at least one scanner that has some extensions to the signature file. These extensions that will not be recognized by TbScan(X) are: - The virus type identifier "PART" or "MAIN". In my opinion viruses that infect only the partition table don't exist and will never exist. Why? Because floppy disks don't have a partition table and are therefore not suitable to carry such a virus. A virus programmer can be pretty sure that his/her victims never share and exchange their fixed disks, so his virus would not reach other systems. So we can conclude that viruses with the keyword PART should also have the keyword BOOT. Besides, there are many bootsector viruses that are capable of infecting partition tables too. The end result is that all signatures with the keyword PART should also have the keyword BOOT, and that viruses with the keyword BOOT should also be searched on the partition table, regardless of the keyword PART. Consider this and you will understand that in almost all cases the words BOOT and PART are functional equal. Even if a BOOT virus is not able to infect a partition table there is no reason why we shouldn't scan for it. There is only one partition table and it is only one disk sector in size, so scanning speed can not be the reason. Why then using two or even three synonymous keywords? I don't know, and I will not implement those keywords. - The virus type identifier "OVL". Only a few people know that the viruses that are able to infect overlay files do so by accident, because there are some linkers that create overlay files which are in reality a kind of normal EXE file, and these files are also treated that way by DOS. The virus "thinks" the file is a normal EXE file, and infects it. The result is that some viruses that infect EXE files are also able to infect some OVL files, it all depends fully on how their infection routine is triggered. In my opinion there are no viruses that will ONLY infect OVL files, because if they do so, they don't have much chance to spread and they will not survive. Besides, infecting these OVL file is the same process as infecting a EXE file, so why should the virus writer add a special routine to prevent EXE files for becoming infected by their virus? I don't know. The result is that the OVL keyword should always be paired with a EXE keyword, and that many EXE viruses can accidentially infect a OVL file. Consider this and you will understand that in almost all cases the words EXE and OVL are equal. And even if a virus would infect only OVL files it is not a real pain to search for those viruses in EXE files too! Anyway, unlike some other scanners, TbScan scans all OVL files automatically for all EXE viruses. Better safe than sorry! - The same story applies to SYS and BIN viruses. The only difference between SYS and BIN files are their extensions, their internal layout is exactly the same! For reasons beyond my comprehension, the author of That Other scanner defined two keywords for the same virus type! Can anybody explain me why it is not a good idea to search for a BIN marked virus in a SYS file? And if so, why did he omit the third synonym "DEV"? - The keyword PIF. I'm not a Windows expert, but I have my doubts whether a file with the extension PIF contains really any executable code. - The keyword UMB. The keywords LOW and UMB are actually the same, as I will explain below in "Notes concerning the scanning of memory". With the release of DOS 5.00 the keyword UMB becomes obsolete anyway. TbScan scans automatically the Upper Memory area for all viruses with the keyword LOW set. - The XOR brackets '{' and '}'. This "scrambling" technique in its pure appearance is so seldomly used and so subject to modifications (mutations!), that this detection scheme is almost useless. Note that these comments are not intended to anoy the author of "That Other scanner", nor to give you the impression that his product is less than mine. In fact, I'm surprised by the speed achieved by that scanner because it has been created with a high level programming language and is not very much slower compared to TbScan. I also borrowed some of the ideas implemented in that scanner. But I have to justify to the users of TbScan(X) why I don't implement these extensions to the data file. Defining a standard is always difficult, especially if the developers don't consult each other before introducing new extensions to the format of the shared input files. :-( Notes concerning the scanning of memory --------------------------------------- TbScan recognizes two types of memory signature: LOW memory and HIGH memory viruses. The keywords are choosen not very carefully: the keyword LOW means that the virus is a normal TSR-type virus which could reside in memory below TbScan, and in upper memory. Both locations are suitable for TSR-type viruses and TbScan will scan both areas for signatures with the keyword LOW set. The keyword HIGH is intended for boot sector viruses (that have to allocate their memory by decreasing the available memory value maintained by the BIOS) and by viruses that allocate memory by manipulating the DOS memory control block chain. Consider this layout: ┌──────────────────────────┐ 0Kb │ │ │ Low memory. │ │ │ LOW │ TSR's are loaded here │ │ │ │ also TSR type viruses │ │ are loaded here. │ ├──────────────────────────┤ │ │ N/A │ TbScan is executed here │ ├──────────────────────────┤ │ │ │ │ │ Free memory │ HIGH │ │ │ │ │ │ │ │ │ │ ├──────────────────────────┤ End of DOS available memory │ Top loaded software │ HIGH │ like MCB manipulators │ │ and some viruses reside │ │ in this area │ ├──────────────────────────┤ 640Kb limit │ │ │ Video memory │ │ ROM's │ │ EMS page frames │ LOW │ and Upper memory │ │ TSR's (and also TSR type │ │ viruses) can reside here │ ├──────────────────────────┤ │ System BIOS │ LOW │ │ ├──────────────────────────┤ 1Mb limit LOW │ HMA │ └──────────────────────────┘ Note that TbScan does not have a special keyword for Upper Memory Viruses. Viruses that are able to use Upper Memory should also be able to use normal LOW memory, because they can not rely that there is Upper Memory in every machine they will reach. Normal TSR-viruses on the other hand can be loaded in Upper Memory using an appropriate highloader as supplied with Qemm or even DOS 5.00. So "UMB-type viruses" are the same as LOW viruses! There is also no need to scan allocated pages of EMS. Viruses can never reside entirely in expanded memory. They should have at least a piece of code outside the EMS window, just to have access to the EMS driver to swap in the correct RAM-pages. By using that piece of code as the search signature also those (future?) viruses will be found, without the need to scan all EMS pages. Some users think it is usefull to scan the memory for all viruses using the -allmem (+r) option of TbScan. I think it is not a good idea, because memory signatures are not the same as disk signatures. There are many scrambled viruses, but in memory they reside unscrambled. The signatures for both instances of the same viruses could be totally different! The same applies to signatures that incorporate uninitialized data. In memory the data is used for some purpose, and the memory values are different. Searching memory for disk-specific signatures is likely to cause false alarms and the signatures will not match the memory image of the virus anyway.